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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 

The present document is one of a series of ECMA Standards defining the interworking of services and signalling 
protocols deployed in Corporate telecommunication Networks (CNs). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00215. 

The present document defines the signalling protocol interworking for call completion supplementary services between 
a Private Integrated Services Network (PISN) and a packet-based private telecommunication network based on the 
Internet Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point 
(QSIG) and that the protocols for the IP-based network are based on ITU-T Recommendation H.323. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document is contributed to ISO/IEC JTC1 under the terms of the fast-track procedure, for adoption as an 
ISO/IEC International Standard. 

The present document has been adopted by the General Assembly of June 2001. 



1 Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of call completion 
supplementary services within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated services Network 
eXchanges (PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in 
ECMA- 133. A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified 
in other ECMA Standards, in particular ECMA- 143 (call control in support of basic services), ECMA- 165 (generic 
functional protocol for the support of supplementary services) and a number of standards specifying individual 
supplementary services. ECMA- 186 specifies the QSIG protocol in support of call completion services. 

"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation 
referring to various ITU-T Recommendations, in particular H.225.0 and H.245 (basic communication capabilities) and 
H.450.1 (generic functional protocol for the support of supplementary services). Recommendation H.450.9 specifies the 
H.323 protocol in support of call completion services. 

NOTE: ITU-T Recommendation H.450.9 applies only to the 1998 version of H.323 (also known as H.323 
version 2) and to later versions. 
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In both ECMA-186 (QSIG) and ITU-Recommendation H.450.9 (H.323), the call completion supplementary services are 
Completion of Calls to Busy Subscribers (SS-CCBS) and Completion of Calls on No Reply (SS-CCNR). These 
supplementary services apply after a call establishment attempt has failed because the called user was busy or not 
available, and provide means to re-establish the call when the called user becomes available. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of a private 
IP network, or a call originating at a user of a private IP network to terminate at a user of a PISN. In such a scenario, the 
present document allows the completion of calls when the called user becomes available after having been busy (SS- 
CCBS), or having not answered the original call (SS-CCNR). 

Interworking between a PISN employing QSIG and a public IP network employing H.323 is outside the scope of the 
present document. However, the functionality specified in the present document is in principle applicable to such a 
scenario when deployed in conjunction with other relevant functionality (e.g., number translation, security functions, 

etc.). 

The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and a private IP network employing H.323. 



Conformance 



In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 



3 References 

The following standards contain provisions which, through reference in this text, constitute provisions of the present 
document. All standards are subject to revision, and parties to agreements based on the present document are 
encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

ECMA-133: "Private Integrated Services Network (PISN) - Reference Configurations for PISN Exchanges (PINX) 
(ISO/IEC 11579-1)". 

ECMA- 143: "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter-Exchange Signalling 
Procedures and Protocol (QSIG-BC) (ISO/IEC 11572)". 

ECMA-165: "Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of 
Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (QSIG-GF) (ISO/IEC 11582)". 

ECMA-186: "Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Completion 
Supplementary Services (QSIG-CC) (ISO/IEC 13870)". 

ECMA-307: "Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 - Generic 
Functional Protocol for the Support of Supplementary Services (ISO/IEC 21409)". 

ITU-T Recommendation H.225.0 (1998 or later): "Call signalling protocols and media stream packetization for packet- 
based multimedia communication systems ". 

ITU-T Recommendation H.245 (1998 or later): "Control protocol for multimedia communication". 

ITU-T Recommendation H.323 (1998 or later): "Packet-based multimedia communications systems". 

ITU-T Recommendation H.450.1 (1998): "Generic functional protocol for the support of supplementary services in 
H.323 ". 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

Call: See ECMA-307. 

Corporate telecommunication Network (CN): See ECMA-307. 

Endpoint: See ITU-T Recommendation H.323. 

Gatekeeper: See ITU-T Recommendation H.323. 

Private Integrated Services Network (PISN): See ECMA-307. 

Private Integrated services Network exchange (PINX): See ECMA-133. 

Additionally the definitions in ECMA-186 and ITU-T Recommendation H.450.9 apply as appropriate. 

4.2 Other definitions 

4.2.1 Entity A 

Signalling entity at the PINX or H.323 endpoint serving the calling user (user A). 

4.2.2 Entity B 

Signalling entity at the PINX or H.323 endpoint serving the called user (user B). 

4.2.3 Gateway 

A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG. 

4.2.4 IP network 

A network, unless otherwise stated a CN, offering connectionless packet-mode services based on the Internet Protocol 
(IP) as the network layer protocol. 

4.2.5 Leg A 

Call segment that lies between entity A and entity B. 

4.2.6 Scenario A1 

Interworking arrangement in which entity A (PINX A) is in the PISN and entity B is in the IP network. 

4.2.7 Scenario A2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and entity B is in the PISN. 



ETSI 



ETSI TS 101 989 V1.1.1 (2001-08) 



Acronyms 



APDU Application Protocol Data Unit 

CN Corporate telecommunication Network 

ICS Implementation Conformance Statement 

IP Internet Protocol 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SS-CC Supplementary Service Call Completion (either SS-CCBS or SS-CCNR) 

SS-CCBS Supplementary Service Completion of Calls to Busy Subscribers 

SS-CCNR Supplementary Service Completion of Calls on No Reply 



6 Service architecture 

6.1 Service architecture for invocation and operation 
6.1.1 ECMA-186 service architecture 

The QSIG protocol for call completion invocation and operation is based around two signalling entities or PINX types: 

• entity A - the PINX serving the calling user (user A); 

• entity B - the PINX serving the called user (user B). 

Where a user is in another network, the role of entity A or entity B is performed by the other network, the gateway or 
the two in combination. However, from the QSIG point of view the role is performed by the gateway, which acts as a 
gateway PINX. 

This can be represented diagrammatically as shown in figure 1 . 



Entity A 



Leg A 



Entity B 



Figure 1 : Call completion architecture 

From this it can be seen that there is only one segment or "leg" as far as the QSIG protocol is concerned (regardless of 
any transit entities through which the signalling may pass). 

However, an instance of SS-CC consists of several consecutive phases, each phase being a separate instance of call 
related or call independent signalling. In other words, leg A in figure 1 represents several calls or call independent 
signalling connections between entities A and B, which all belong to a single instance of SS-CC but may take different 
routes through the network. 

The typical course of action for an instance of SS-CC is: 

• Prerequisite: unsuccessful call attempt because of busy or absent user B; 

• invocation of SS-CC, using a call independent signalling connection (signalling phase 1); 

• monitoring of user B; there is no (network) signalling involved during this phase; 

• user B available notification, using call independent signalling, and suspension/resumption of SS-CC if user A is 
busy at this stage (signalling phase 2); 

• recall, resulting in an automatically initiated basic call from user A to user B (signalling phase 3); 
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• cancellation of SS-CC, by the network (e.g. after timeout), or by user A or user B at any time (signalling 
phase 4). 

NOTE: Interworking is only concerned with the phases that involve (network) signalling. 

6.1 .2 H.450.9 service architecture 

The architecture shown above for QSIG applies also to H.450.9, except that PINXs are replaced by H.323 entities as 
follows: 

• entity A - the calling endpoint; 

• entity B - the called endpoint. 

Either entity can alternatively be located at a gatekeeper or proxy (as defined in H.450.9) acting on behalf of the 
respective endpoint, the signalling between endpoint and gatekeeper/proxy being outside the scope of H.450.9. In this 
case the gatekeeper/proxy performs the role of entity A or B, respectively. However, from the H.450.9 point of view the 
role is performed by the endpoint. 

Where a user is in another network, the role of entity A or entity B is performed by the other network, the gateway or 
the two in combination. However, from the H.450.9 point of view the role is performed by the gateway. 

6.1 .3 Scenarios for interworking 

The architectures for ECMA-186 and H.450.9 are very similar. 

This means that the same architecture is applicable to the inter-networking situation between an IP network and a PISN, 
where one user involved is served by the IP network and the other is served by the PISN. 

For the point of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies: 

• Scenario Al : Entity A (PINX A) in PISN, entity B (endpoint B) in IP network; 

• Scenario A2: Entity A (endpoint A) in IP network, entity B (PINX B) in PISN. 

The point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of 
view of the IP network and a gateway PINX from the point of view of the PISN. 

6.1 .4 Selection of the same gateway for all phases 

Since the different phases of an SS-CC instance in general use separate signalling paths, messages belonging to 
different phases may pass through different gateways. In this situation it does not make sense for a gateway to maintain 
SS-CC related states on either side, unless it can be assured that all signalling for a particular SS-CC instance passes 
through the same gateway. This is the case if there is only one gateway available for connecting the particular pair of 
users A and B at any time, but usually not if the load is shared dynamically between several gateways. 

One possible way to always choose the same gateway is by means of addressing. If the gateways themselves are 
addressable entities with their own alias addresses/PISN numbers - in contrast to being only indirectly addressed via the 
alias addresses/PISN numbers of users reachable through the gateway - a specific gateway can be selected: 

• on the IP side of the gateway, by using both elements destinationAddress (=gateway address) and 
remoteExtensionAddress (=PISN user address) within the relevant address fields of the H.450.9 APDUs or the 
Setup message; 

• on the PISN side of the gateway, by using a (temporary) gateway number, selected (by the gateway) to represent 
the remote user in this instance of SS-CC at this gateway. The gateway then has to map between the temporarily 
assigned number and the pair of elements destinationAddress! remoteExtensionAddress. 

However, the interworking procedures specified in the present document do not by themselves require the use of the 
same gateway for all signalling related to a particular instance of SS-CC. 

NOTE: It will be required if connection retention and connection release methods have to be interworked (see 6.2 
and 8.1 for more information). 
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6.2 Options 



SS-CC can be - and has been - implemented in different ways. Both QSIG and H.323 offer several options, mainly for 
ease of interworking with existing implementations in other networks. 

The following options of SS-CC can be selected by implementations both in QSIG and in H.323: 

• Service retention: If a CC call attempt fails because user B is busy again, SS-CC may either re-enter the 
monitoring phase (service retention) or be cancelled (service non-retention). 

• Connection retain/release method: A call independent signalling connection may or may not be maintained 
between entities A and B during monitoring phases, i.e. phases without signalling. 

For both options negotiation is possible, and both can be interworked between QSIG and H.323. 

The following option is only available in QSIG: 

• Path reservation/non-reservation: A network path is established for the CC call before informing user A (path 
reservation), or user A is informed first and the CC call is then established as a basic call upon acceptance by 
user A (path non-reservation). 

H.323 supports only path non-reservation, therefore path reservation cannot be directly interworked. 



7 Protocol interworking - General requirements 

Protocol interworking between H.323 and QSIG for call completion supplementary services shall be in accordance with 
ECMA-307, as modified by the requirements of clause 8. 

When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the 
mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance 
with ECMA-307, where applicable. Optional elements of one protocol that have no corresponding element in the other 
protocol shall be discarded if received. 



8 Protocol interworking - Messages and APDUs 

In the rules specified below for the different scenarios, the following apply: 

If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a 
FACILITY message to be sent at that time, the action to be taken is an implementation matter. 

If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that 
message being transmitted and that message is not to be transmitted (owing to basic call interworking 
considerations), the action to be taken is an implementation matter. 

If the required action is dependent on the call independent signalling connection extending or being able to be 
extended into the other network and this cannot be achieved, the action to be taken is an implementation matter. 

8.1 Signalling phase 1 - invocation of call completion 

The invocation procedure of call completion uses a call independent signalling connection, which may be retained for 
signalling phase 2 onwards (see below) or released at the end of signalling phase 1 . 

The interworking rules imply that the signalling connection is either retained on both sides or released on both sides of 
the gateway. Interworking scenarios where the connection is released on one side and retained on the other are not 
provided for. 
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NOTE 1 : Element retain-sig-connection in the ccbsRequest/ccnrRequest invoke APDU will be passed on by the 
gateway if present and allows entity A to ask for a specific method. Entity B will honour this request 
unless further interworking requires a different method. If the element is not present entity B will choose 
the method. 

NOTE 2: A possible reason for "mixed" scenarios is a concatenation of networks some of which are neither H.323 
nor QSIG. An implementation may support such scenarios in a proprietary way. In this case the side 
without signalling connection must be able to locate the gateway initially used (which has retained the 
connection on the other side). Clause 6.1.4 shows how this could be achieved. 

Service retention is negotiated end-to-end between entities A and B. 

8.1.1 Scenario A1 

A gateway that supports scenario Al shall behave in accordance with the rules of table 1, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of an H.323 message from entity B. 

Table 1 : Message and APDU handling requirements for signalling phase 1, scenario A1 



Rule 


Condition 


Required action 


1.1 


Receipt of a QSIG SETUP message for a call 
independent signalling connection, containing a 
QSIG ccbsRequest or ccnrRequest invoke APDU. 


If the call independent signalling connection can be 
extended into the IP network, transmit an H.323 
SETUP message for a call independent signalling 
connection, containing an H.323 ccbsRequest or 
ccnrRequest invoke APDU. 


1.2 


Receipt of an H.323 CONNECT message 
containing an H.323 ccbsRequest or ccnrRequest 
return result APDU. 


If a QSIG CONNECT message is to be transmitted, 
include in the QSIG CONNECT message a QSIG 
ccbsRequest or ccnrRequest return result APDU. 


1.3 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 ccbsRequest or 
ccnrRequest return result APDU. 


Transmit a QSIG RELEASE message containing a 
QSIG ccbsRequest or ccnrRequest return result APDU 
if the QSIG call state permits. 


1.4 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 ccbsRequest or 
ccnrRequest return error APDU. 


Transmit a QSIG RELEASE message containing a 
QSIG ccbsRequest or ccnrRequest return error APDU 
if the QSIG call state permits. 



8.1.2 Scenario A2 

A gateway that supports scenario A2 shall behave in accordance with the rules of table 2, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity A, or 
receipt of a QSIG message from entity B. 

Table 2: Message and APDU handling requirements for signalling phase 1, scenario A2 



Rule 


Condition 


Required action 


1.1 


Receipt of an H.323 SETUP message for a call 
independent signalling connection, containing an 
H.323 ccbsRequest or ccnrRequest invoke 
APDU. 


If the call independent signalling connection can be 
extended into the PISN, transmit a QSIG SETUP 
message for a call independent signalling connection, 
containing a QSIG ccbsRequest or ccnrRequest invoke 
APDU. 


1.2 


Receipt of a QSIG CONNECT message 
containing a QSIG ccbsRequest or ccnrRequest 
return result APDU. 


If an H.323 CONNECT message is to be transmitted, 
include in the H.323 CONNECT message an H.323 
ccbsRequest or ccnrRequest return result APDU. 


1.3 


Receipt of a QSIG RELEASE message 
containing a QSIG ccbsRequest or ccnrRequest 
return result APDU. 


Transmit an H.323 RELEASE COMPLETE message 
containing an H.323 ccbsRequest or ccnrRequest 
return result APDU if the H.323 call state permits. 


1.4 


Receipt of a QSIG RELEASE message 
containing a QSIG ccbsRequest or ccnrRequest 
return error APDU. 


Transmit an H.323 RELEASE COMPLETE message 
containing an H.323 ccbsRequest or ccnrRequest 
return error APDU if the H.323 call state permits. 
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8.2 Signalling phase 2 - user B available notification 

The procedures of this phase use either the retained call independent signalling connection or a new one if the previous 
one was released after signalling phase 1 . 

If user A is busy at this stage, SS-CC will be suspended and resumed when user A becomes free, which will result in 
monitoring the status of user B again, and signalling phase 2 will eventually be re-entered. However, in scenario A2 
there is a slight danger of incompatible protocol states at entities A and B caused by one specific combination of options 
where QSIG and H.323 deviate. The procedures below specify a method to resolve this conflict with a high probability 
of success. 

If user A is not busy the service will proceed from signalling phase 2 to signalling phase 3 (or signalling phase 4 in case 
of failure). 

8.2.1 Scenario A1 

A gateway that supports scenario Al shall behave in accordance with the rules of table 3, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of an H.323 message from entity B. 

Table 3: Message and APDU handling requirements for signalling phase 2, scenario A1 



Rule 


Condition 


Required action 


2.1 


Receipt of an H.323 SETUP message for a call 
independent signalling connection, containing an 
H.323 ccExecPossible invoke APDU. 


If the call independent signalling connection can be 
extended into the PISN, transmit a QSIG SETUP 
message containing a QSIG ccExecPossible invoke 
APDU. 


2.2 


Receipt of an H.323 FACILITY message 
containing an H.323 ccExecPossible invoke 
APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG ccExecPossible invoke APDU if the QSIG call 
state permits. 


2.3 


Receipt of a QSIG FACILITY message containing 
a QSIG ccSuspend invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 ccSuspend invoke APDU if the H.323 call state 
permits. 


2.4 


Receipt of a QSIG RELEASE message containing 
a QSIG ccSuspend invoke APDU. (Note) 


Transmit an H.323 RELEASE COMPLETE message 
containing an H.323 ccSuspend invoke APDU if the 
H.323 call state permits. 


2.5 


Receipt of a QSIG CONNECT message 
containing a QSIG ccSuspend invoke APDU. 


If an H.323 CONNECT message is to be transmitted, 
include in the H.323 CONNECT message an H.323 
ccSuspend invoke APDU. 


2.6 


Receipt of a QSIG FACILITY message containing 
a QSIG ccResume invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 ccResume invoke APDU if the H.323 call state 
permits. 


NOTE: This should not occur as it is a path reservation specific procedure, but causes no harm on the H.323 side. 



8.2.2 Scenario A2 

A gateway that supports scenario A2 shall behave in accordance with the rules of table 4, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity A, or 
receipt of a QSIG message from entity B. 
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Table 4: Message and APDU handling requirements for signalling phase 2, scenario A2 



Rule 


Condition 


Required action 


2.1 


Receipt of a QSIG SETUP message for a call 
independent signalling connection, containing a 
QSIG ccExecPossible invoke APDU. 


If the call independent signalling connection can be 
extended into the IP network, transmit an H.323 
SETUP message containing an H.323 ccExecPossible 
invoke APDU. 


2.2 


Receipt of a QSIG FACILITY message containing 
a QSIG ccExecPossible invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 ccExecPossible invoke APDU if the H.323 call 
state permits. 


2.3 


Receipt of an H.323 FACILITY message containing 
an H.323 ccSuspend invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG ccSuspend invoke APDU if the QSIG call state 
permits. 


2.4 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 ccSuspend invoke 
APDU. 


Transmit a QSIG RELEASE message without a QSIG 
ccSuspend invoke APDU if the QSIG call state permits, 
(notel) 


2.5 


Receipt of an H.323 CONNECT message 
containing an H.323 ccSuspend invoke APDU. 


If a QSIG CONNECT message is to be transmitted, 
include in the QSIG CONNECT message a QSIG 
ccSuspend invoke APDU. 


2.6 


Receipt of an H.323 FACILITY message containing 
an H.323 ccResume invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG ccResume invoke APDU if the QSIG call state 
permits. 


2.7 


Receipt of an H.323 SETUP message for a call 
independent signalling connection containing an 
H.323 ccResume invoke APDU. 


Return a ccExecPossible invoke APDU (omitting the 
argument or including it in the short form) in an H.323 
FACILITY message, followed by an H.323 RELEASE 
COMPLETE message (note 2). 


NOTE 1 : Sending of a ccSuspend invoke APDU in a RELEASE message would be possible in QSIG, but then the 

following CC call is expected to use path reservation. The suppression of ccSuspend at the gateway in this case 
avoids inconsistent protocol states at entities A and B at the expense of a possible (implementation specific) 
timeout in entity B. 

NOTE 2: The ccResume cannot be passed on in a SETUP message on the QSIG side. Due to the likely protocol state at 
entity B, inviting entity A to initiate signalling phase 3 offers the best chance of successfully completing the 
service. In this case the gateway is responsible for clearing the signalling connection on the H.323 side and 
suppressing a ccSuspend invoke APDU which may be received (in a FACILITY message) in response to 
ccExecPossible. 



8.3 Signalling phase 3 - CC call establishment 

The procedures of this signalling phase are call related. Because H.450.9 does not specify a path reservation method, 
the actions specified below result in the rejection of a QSIG path reservation request. 

8.3.1 Scenario A1 

A gateway that supports scenario Al shall behave in accordance with the rules of table 5, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of an H.323 message from entity B. 

Table 5: Message and APDU handling requirements for signalling phase 3, scenario A1 



Rule 


Condition 


Required action 


3.1 


Receipt of a QSIG SETUP message containing a 
QSIG ccRingout invoke APDU. 


If an H.323 SETUP message is to be transmitted, 
include in the H.323 SETUP message an H.323 
ccRingout invoke APDU. 


3.2 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 ccRingout return error 
APDU. 


Transmit a QSIG DISCONNECT message containing a 
QSIG ccRingout return error APDU if the QSIG call 
state permits. 


3.3 


Receipt of a QSIG SETUP message containing a 
QSIG ccPathReserve invoke APDU. 


No mapping, return a QSIG DISCONNECT message 
including a ccPathReserve return error APDU with 
value 'failedDueTolnterworking'. 
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8.3.2 Scenario A2 

A gateway that supports scenario A2 shall behave in accordance with the rules of table 6, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity A, or 
receipt of a QSIG message from entity B. 

Table 6: Message and APDU handling requirements for signalling phase 3, scenario A2 



Rule 


Condition 


Required action 


3.1 


Receipt of an H.323 SETUP message containing 
an H.323 ccRingout invoke APDU. 


If a QSIG SETUP message is to be transmitted, 
include in the QSIG SETUP message a QSIG 
ccRingout invoke APDU. 


3.2 


Receipt of a QSIG DISCONNECT message 
containing a QSIG ccRingout return error APDU. 


Transmit an H.323 RELEASE COMPLETE message 
containing an H.323 ccRingout return error APDU if 
the H.323 call state permits. 



8.4 Signalling phase 4 - cancellation of SS-CC 

This phase covers the unsuccessful termination of an SS-CC instance either through an explicit request for cancellation 
or through exception handling (e.g. timeout). It does not occur if an instance of SS-CC terminates successfully. The 
cancellation procedures apply anytime after signalling phase 1 is completed. They use call independent signalling. 

8.4.1 Scenario A1 

A gateway that supports scenario Al shall behave in accordance with the rules of table 7, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of an H.323 message from entity B. 

Table 7: Message and APDU handling requirements for cancellation, scenario A1 



Rule 


Condition 


Required action 


4.1 


Receipt of a QSIG SETUP message for a call 
independent signalling connection, containing a 
QSIG ccCancel invoke APDU. 


If the call independent signalling connection can be 
extended into the IP network, transmit an H.323 SETUP 
message containing an H.323 ccCancel invoke APDU. 


4.2 


Receipt of a QSIG RELEASE message containing a 
QSIG ccCancel invoke APDU. 


Transmit an H.323 RELEAE COMPLETE message 
containing an H.323 ccCancel invoke APDU if the H.323 
call state permits. 


4.3 


Receipt of an H.323 SETUP message for a call 
independent signalling connection, containing an 
H.323 ccCancel invoke APDU. 


If the call independent signalling connection can be 
extended into the PISN, transmit a QSIG SETUP 
message containing a QSIG ccCancel invoke APDU. 


4.4 


Receipt of an H.323 RELEASE COMPLETE 
message containing an H.323 ccCancel invoke 
APDU. 


Transmit a QSIG RELEASE message containing a QSIG 
ccCancel invoke APDU if the QSIG call state permits. 



8.4.2 Scenario A2 

A gateway that supports scenario A2 shall behave in accordance with the rules of table 8, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity A, or 
receipt of a QSIG message from entity B. 
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Table 8: Message and APDU handling requirements for cancellation, scenario A2 



Rule 


Condition 


Required action 


4.1 


Receipt of an H.323 SETUP message for a call 
independent signalling connection, containing an 
H.323 ccCancel invoke APDU. 


If the call independent signalling connection can be 
extended into the PISN, transmit a QSIG SETUP 
message containing a QSIG ccCancel invoke APDU. 


4.2 


Receipt of an H.323 RELEASE COMPLETE message 
containing an H.323 ccCancel invoke APDU. 


Transmit a QSIG RELEASE message containing a 
QSIG ccCancel invoke APDU if the QSIG call state 
permits. 


4.3 


Receipt of a QSIG SETUP message for a call 
independent signalling connection, containing a QSIG 
ccCancel invoke APDU. 


If the call independent signalling connection can be 
extended into the IP network, transmit an H.323 
SETUP message containing an H.323 ccCancel 
invoke APDU. 


4.4 


Receipt of a QSIG RELEASE message containing a 
QSIG ccCancel invoke APDU. 


Transmit an H.323 RELEAE COMPLETE message 
containing an H.323 ccCancel invoke APDU if the 
H.323 call state permits. 





9 Protocol interworking - content of APDUs 

This clause contains the requirements for the mapping of elements that are not covered by the general requirements in 
clause 7. Rules are provided: 

• for elements that are mandatory in at least one of the protocols (optional elements that cannot be mapped may be 
discarded if received); 

• for elements which require a specific setting due to interworking between QSIG and H.323; 

• for elements which have no equivalent in the other protocol. 

9.1 APDU content mapping from QSIG to H.323 
9.1 .1 ccbsRequest/ccnrRequest invoke APDU mapping 

When transmitting an H.323 ccbsRequest/ccnrRequest invoke APDU as a result of receiving a QSIG 
ccbsRequest/ccnrRequest invoke APDU, a gateway shall map elements in accordance with table 9. 

Table 9: ccbsRequest/ccnrRequest invoke APDU mapping from QSIG to H.323 



element name 


QSIG element type 

"(M)" denotes mandatory 

element 


H.323 element type 
"(M)" denotes mandatory element 


Mapping requirement 


service 


PSS1 InformationElement (M) 

with embedded 

BC[,LLC][,HLC] 

Information transfer capability: 

speech 

unrestr. digital information 

3,1 kHz audio 


BasicService (ENUMERATED) (M) 

speech 

unrestrictedDigitallnformation 

audio3100Hz 


Ignore LLC and HLC 
Map if BC contains coding 
standard = ITU-T', transfer 
mode = 'circuit mode' and 
information transfer rate = 
'64kbit/s', otherwise reject 
operation 

Further mapping rules are 
outside the scope of the 
present document 


can-retain- 
service 


BOOLEAN 


BOOLEAN (M) 


Set to 'FALSE' if not present 



9.1 .2 ccbsRequest/ccnrRequest return result APDU mapping 

When transmitting an H.323 ccbsRequest/ccnrRequest return result APDU as a result of receiving a QSIG 
ccbsRequest/ccnrRequest return result APDU, a gateway shall map elements in accordance with table 10. 
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Table 10: ccbsRequest/ccnrRequest return result APDU mapping from QSIG to H.323 



element 
name 


QSIG element type 
"(M)" denotes mandatory element 


H.323 element type 
"(M)" denotes mandatory element 


Mapping requirement 


retain-service 


BOOLEAN 


BOOLEAN (M) 


Set to 'FALSE' if not present 



9.1 .3 ccCancel/ccExecPossible invoke APDU mapping 

When transmitting an H.323 ccCancel or ccExecPossible invoke APDU with argument longArg, as a result of receiving 
a QSIG ccCancel or ccExecPossible invoke APDU with argument fullArg (in a SETUP message), a gateway shall map 
element service in accordance with table 9 above. 

9.2 APDU content mapping from H.323 to QSIG 
9.2.1 ccbsRequest/ccnrRequest invoke APDU mapping 

When transmitting a QSIG ccbsRequest/ccnrRequest invoke APDU as a result of receiving an H.323 
ccbsRequest/ccnrRequest invoke APDU, a gateway shall map elements in accordance with table 1 1 . 

Table 11 : ccbsRequest/ccnrRequest invoke APDU mapping from H.323 to QSIG 



element 


H.323 element type 


QSIG element type 


Mapping requirement 


name 


"(M)" denotes mandatory 


"(M)" denotes mandatory 






element 


element 




service 


BasicService (ENUMERATED) (M) 


PSS1 InformationElement (M) with 


Do not generate LLC and 






embedded BC[,LLC][,HLC] 


HLC 




speech 


Information transfer capability: 


Map BC as indicated 




unrestrictedDigitallnformation 


speech 


Further mapping rules are 




audio3100Hz 


unrestr. digital information 


outside the scope of the 






3.1 kHz audio 


present document 






Coding standard = ITU-T, 








Transfer mode = 'circuit mode' 








Information transfer rate = '64kbit/s' 





9.2.2 ccbsRequest/ccnrRequest return result APDU mapping 

When transmitting a QSIG ccbsRequest/ccnrRequest return result APDU as a result of receiving an H.323 
ccbsRequest/ccnrRequest return result APDU, a gateway shall map elements in accordance with table 12. 

Table 12: ccbsRequest/ccnrRequest return result APDU mapping from H.323 to QSIG 



element 
name 


H.323 element type 

"(M)" denotes mandatory 

element 


QSIG element type 
"(M)" denotes mandatory element 


Mapping requirement 


no-path- 
reservation 


— 


BOOLEAN 


Set to TRUE' 



9.2.3 ccCancel/ccExecPossible invoke APDU mapping 

When transmitting a QSIG ccCancel or ccExecPossible invoke APDU as a result of receiving an H.323 ccCancel or 
ccExecPossible invoke APDU with argument longArg (in a SETUP message), a gateway shall map elements in 
accordance with table 13. 
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Table 13: ccCancel/ccExecPossible invoke APDU mapping from H.323 to QSIG 



H.323 element name/type 
"(M)" denotes mandatory element 


QSIG element name/type 
"(M)" denotes mandatory element 


Mapping requirement 


longArg (SEQUENCE): 
numberA 
numberB 
ccldentifier 
service 


fullArg (SEQUENCE): 
numberA (M) 
numberB (M) 

service (M) 


Discard APDU if one or more of the 
elements numberA, numberB, 
service are missing (further actions 
implementation dependent) 
map service as indicated in table 1 1 
above 
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Annex A (normative): 

Implementation Conformance Statement (ICS) proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

A.1 .1 Purpose of an ICS proforma 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

- by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, e.g. 
through oversight; 

- by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

- by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

- by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. 
Each item is identified by an item reference, the description of the item (question to be answered), and the reference(s) 
to the clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 

M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the support 

column is required; 
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O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 

0.<n> qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 



A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

"Qualification" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause in A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 
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A.3 
A.3.1 



Identification of the Implementation 
Implementation Identification 



Supplier (note 1) 




Contact point for queries about the ICS (note 1 ) 




Implementation Name(s) and Version(s) (notes 1 
and 2) 




Other information necessary for full identification 
- e.g., name(s) and version(s) for machines 
and/or operating systems; System name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information may be 
completed as appropriate in meeting the requirement for full identification. 

NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a 
suppliers terminology (e.g. Type, Series, Model). 



A.3. 2 Specification for which this ICS applies 



Title 


Corporate Telecommunication Networks (CN); 
Signalling interworking between QSIG and H.323; Call 
Completion supplementary services. 


Version 


1.1.1 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does 

not conform to the present document) (note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper. 
Nature of non-conformance (if applicable): 



A.4 Major capabilities 



Table A.1 : Major capabilities 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MC1 


support scenario A1 




M 


6.1.3 


[]Yes 


MC2 


support scenario A2 




M 


6.1.3 


[]Yes 


MC3 


support selection of the same gateway for all 
phases 




O 


6.1.4 


[ ]Yes [ ]No 


MC4 


support the connection release method 




M 


6.2 


[ ]Yes [ ]No 


MC5 


support the connection retention method 




M 


6.2 


[ ]Yes [ ]No 


Comments: 
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A.5 General requirements 

Table A.2: General requirements for protocol interworking 



A. 6 Message and APDU handling 

A.6.1 Message and APDU handling for scenario A1 

Table A.3: Message and APDU handling for scenario A1 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


GR1 


perform protocol interworking in 
accordance with ECMA-307 




M 


7 


[ ]Yes 


Comments: 





Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MM 1 


behave in accordance with rule 1 .1 for 
scenario A1 




M 


8.1.1 


[]Yes 


MA1 2 


behave in accordance with rule 1 .2 for 
scenario A1 




M 


8.1.1 


[]Yes 


MA1 3 


behave in accordance with rule 1 .3 for 
scenario A1 




M 


8.1.1 


[]Yes 


MA1 4 


behave in accordance with rule 1 .4 for 
scenario A1 




M 


8.1.1 


[]Yes 


MA1 5 


behave in accordance with rule 2.1 for 
scenario A1 




M 


8.2.1 


[]Yes 


MA1 6 


behave in accordance with rule 2.2 for 
scenario A1 




M 


8.2.1 


[]Yes 


MA1 7 


behave in accordance with rule 2.3 for 
scenario A1 




M 


8.2.1 


[]Yes 


MA1 8 


behave in accordance with rule 2.4 for 
scenario A1 




M 


8.2.1 


[]Yes 


MA1 9 


behave in accordance with rule 2.5 for 
scenario A1 




M 


8.2.1 


[]Yes 


MA1 10 


behave in accordance with rule 2.6 for 
scenario A1 




M 


8.2.1 


[]Yes 


MA1 11 


behave in accordance with rule 3.1 for 
scenario A1 




M 


8.3.1 


[]Yes 


MA1 12 


behave in accordance with rule 3.2 for 
scenario A1 




M 


8.3.1 


[]Yes 


MA1 13 


behave in accordance with rule 3.3 for 
scenario A1 




M 


8.3.1 


[]Yes 


MA1 14 


behave in accordance with rule 4.1 for 
scenario A1 




M 


8.4.1 


[]Yes 


MA1 15 


behave in accordance with rule 4.2 for 
scenario A1 




M 


8.4.1 


[]Yes 


MA1 16 


behave in accordance with rule 4.3 for 
scenario A1 




M 


8.4.1 


[]Yes 


MA1 17 


behave in accordance with rule 4.4 for 
scenario A1 




M 


8.4.1 


[]Yes 


Comments: 
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A.6.2 Message and APDU handling for scenario A2 

Table A.4: Message and APDU handling for scenario A2 



Item 


Question: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MA2 1 


behave in accordance with rule 1 .1 for 
scenario A2 




M 


8.1.2 


[]Yes 


MA2 2 


behave in accordance with rule 1 .2 for 
scenario A2 




M 


8.1.2 


[]Yes 


MA2 3 


behave in accordance with rule 1 .3 for 
scenario A2 




M 


8.1.2 


[]Yes 


MA2 4 


behave in accordance with rule 1 .4 for 
scenario A2 




M 


8.1.2 


[]Yes 


MA2 5 


behave in accordance with rule 2.1 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 6 


behave in accordance with rule 2.2 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 7 


behave in accordance with rule 2.3 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 8 


behave in accordance with rule 2.4 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 9 


behave in accordance with rule 2.5 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 10 


behave in accordance with rule 2.6 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 11 


behave in accordance with rule 2.7 for 
scenario A2 




M 


8.2.2 


[]Yes 


MA2 12 


behave in accordance with rule 3.1 for 
scenario A2 




M 


8.3.2 


[]Yes 


MA2 13 


behave in accordance with rule 3.2 for 
scenario A2 




M 


8.3.2 


[]Yes 


MA2 14 


behave in accordance with rule 4.1 for 
scenario A2 




M 


8.4.2 


[]Yes 


MA2 15 


behave in accordance with rule 4.2 for 
scenario A2 




M 


8.4.2 


[]Yes 


MA2 16 


behave in accordance with rule 4.3 for 
scenario A2 




M 


8.4.2 


[]Yes 


MA2 17 


behave in accordance with rule 4.4 for 
scenario A2 




M 


8.4.2 


[]Yes 


Comments: 
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A.7 APDU content mapping 



Table A.5: APDU content mapping 



Item 


Major capability: 
Does the implementation... 


Conditions for 
status 


Status 


Reference 


Support 


MAPI 


behave in accordance with mapping from 
QSIG ccbsRequest/ccnrRequest invoke 
APDU to H.323 ccbsRequest/ccnrRequest 
invoke APDU 


MA1 1 


M 


9.1.1 


[]Yes 


MAP 2 


behave in accordance with mapping from 
QSIG ccbsRequest/ccnrRequest return result 
APDU to H.323 ccbsRequest/ccnrRequest 
return result APDU 


MA1 2 OR MA1 3 


M 


9.1.2 


[]Yes 


MAP 3 


behave in accordance with mapping from 
QSIG ccCancel/ccExecPossible invoke 
APDU to H.323 ccCancel/ccExecPossible 
invoke APDU 


MA2 5 OR MA1 
14 OR MA2 16 


M 


9.1.3 


[]Yes 


MAP 4 


behave in accordance with mapping from 
H.323 ccbsRequest/ccnrRequest invoke 
APDU to QSIG ccbsRequest/ccnrRequest 
invoke APDU 


MA2 1 


M 


9.2.1 


[]Yes 


MAP 5 


behave in accordance with mapping from 
H.323 ccbsRequest/ccnrRequest return result 
APDU to QSIG ccbsRequest/ccnrRequest 
return result APDU 


MA2 2 OR MA2 3 


M 


9.2.2 


[]Yes 


MAP 6 


behave in accordance with mapping from 
H.323 ccCancel/ccExecPossible invoke 
APDU to QSIG ccCancel/ccExecPossible 
invoke APDU 


MA1 5 OR MA1 
16 OR MA2 14 


M 


9.2.3 


[]Yes 


Comments: 
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Annex B (informative): 
Message flow examples 



This annex contains some examples of typical message sequences for the scenarios identified in the present document. 
Although the examples shown are typical, other valid message sequences are possible. 

In the figures, the arrows indicate the direction of messages. For each message, only the message name and the 
contained APDU (if applicable) are shown. Other message contents are not shown. 

The following abbreviations are used: 

.inv invoke APDU 

.res return result APDU 



B.1 Scenario A1 



PISN 



Interworking unit 



IP network 



Call attempt failed because user B is busy 



QSIG SETUP 
ccbsRequest.inv 



QSIG RELEASE 
ccbsRequest.res 



QSIG SETUP 
ccExecPossible.inv 



QSIG RELEASE 



QSIG SETUP 
ccRingout.inv 



H.225.0 Setup 
ccbsRequest.inv 



H.225.0 Release Complete 
ccbsRequest.res 



monitoring user B 



H.225.0 Setup 
ccExecPossible.inv 



user B 
free 



H.225.0 Release Complete 



H.225.0 Setup 
ccRingout.inv 



Figure B.1 : Example of scenario A1 : successful call completion on busy, connection release option 
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PISN 



Interworking unit 



IP network 



Call attempt failed because user B is busy 



QSIG SETUP 
ccbsRequest.inv 



QSIG CONNECT 
ccbsRequest.res 



QSIG FACILITY 
ccExecPossible.inv 



QSIG RELEASE 



QSIG SETUP 
ccRingout.inv 



H.225.0 Setup 
ccbsRequest.inv 



H.225.0 Connect 
ccbsRequest.res 



monitoring user B 



H.225.0 Facility 
ccExecPossible.inv 



user B 
free 



H.225.0 Release Complete 



H.225.0 Setup 
ccRingout.inv 



Figure B.2: Example of scenario A1 : successful call completion on busy, connection retention option 
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B.2 Scenario A2 



IP network 



Interworking unit 



PISN 



Call attempt failed because user B is busy 



H.225.0 Setup 
ccbsRequest.inv 



H.225.0 Release Complete 
ccbsRequest.res 



H.225.0 Setup 
ccExecPossible.inv 



H.225.0 Release Complete 



H.225.0 Setup 
ccRingout.inv 



QSIG SETUP 
ccbsRequest.inv 



QSIG RELEASE 
ccbsRequest.res 



monitoring user B 



QSIG SETUP 
ccExecPossible.inv 



user B 
free 



QSIG RELEASE 



QSIG SETUP 
ccRingout.inv 



Figure B.3: Example of scenario A2: successful call completion on busy, connection release option 
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IP network 


Interworking unit 




PISN 


















Call attempt failed because user B is busy 








— fe. 










H.225.0 Setup 
ccbsRequest.inv 




^ 


QSIG SETUP 
ccbsRequest.inv 


► 


^ 


^ 
^ 






H.225.0 Connect 
ccbsRequest.res 




QSIG CONNECT 
ccbsRequest.res 








monitorir 


ig user B 








user B 


^ 


QSIG FACILITY 
ccExecPossible.in* 


free 


H.225.0 Facility 
ccExecPossible.inv 


k. 


/ 


H.225.0 Release Complete 




QSIG RELEASE 


— w 






^ 


H.225.0 Setup 
ccRingout.inv 




QSIG SETUP 
ccRingout.inv 


w 



Figure B.4: Example of scenario A2: successful call completion on busy, connection retention option 
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Annex C (informative): 
Bibliography 

ITU-T Recommendation H.450.9 (2000): "Call Completion Supplementary Services for H.323". 
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